A modern computer system typically comprises a variety of different interconnected processors, each executing its own software. A single central processing unit (CPU) is typically the basic workhorse of the computer, but other processors control disk storage devices, printers, terminals, communications with other computers, etc. Even more remote and primitive processors may control other functions, such as monitoring sensors, input keypads, etc. In addition, multiple computer systems may be connected to a network, whereby they may communicate with each other.
In such a system, it is common for multiple system components to interact with each other. For example, interacting software modules may be running in separate processors or in a single processor. Processors which control peripheral functions, such as disk storage controllers, must be able to transmit data to and from the system CPU using some defined protocol. Therefore the software running in the peripheral processor must be compatible with the operating system software of the main system. Similarly, multiple software modules may be sharing the CPU and certain system resources. These modules may interact, for example, by sharing memory, and must be compatible in the way they access and alter the shared data.
System components, and particularly software modules, are subject to frequent revision, either to correct known errors in the component or to enhance its function. As a result of these frequent revisions, many versions of a component may exist, each with slightly different capabilities. Some versions of a component may therefore be incompatible with some versions of an interacting module. For example, if software modules A and B share a data structure, the addition of a new function to module A may require a new field in the data structure, and consequently require a new version of module B to support this new field.
Where multiple software modules are licensed from a single source and as a single package, the software developers can solve the problem of incompatible revision levels by guaranteeing that all modules shipped as part of the package are compatible with each other. A number of techniques exist in the art for tracking changes to software in the development environment and testing interacting modules before shipment to the customer to verify compatibility. However, where one module must interact with another from a different source, or that may have been acquired from the same source at a different time, the problem becomes more complex.
One approach to the problem is to allow the modules to execute and let standard system error recovery procedures detect incompatibility. While this may work in some cases, there is no guarantee that the system error recovery procedures will always detect incompatibility. For example, the incompatibility may be one which will corrupt data without generating an error condition. Another approach is to require that all modules be at the same level. While this guarantees module compatibility, it is unduly restrictive. Some modules may be compatible with each other even though not at the same level. This problem is particularly acute in the case of components which are not easily replaced as for example, when software for a peripheral controller is stored in a read-only memory. There exists a need for a general method of verifying compatibility of system components, which will not prevent compatible components of differing version levels from interacting.
It is therefore an object of the present invention to provide an enhanced method and apparatus for verifying compatibility of a plurality of interacting system components.
It is therefore an object of the present invention to provide an enhanced method and apparatus for verifying compatibility of a plurality of interacting software modules.
Another object of this invention to provide a more reliable method and apparatus for detecting component incompatibility.
Another object of this invention is to reduce the instances of reported incompatibility among interacting components which are in fact compatible.
Another object of this invention is to reduce the need for replacing interacting components which are in fact compatible.
Another object of this invention is to reduce the cost of operating a computer system with multiple interacting system components.